@UjinT34

cm_fs_passthrough = 1 is meant to solve this (should switch back to sdr).
Do you really want to keep monitor in HDR mode and have less than ideal SDR -> HDR without DS while the content is SDR and is compatible with DS? Doesn't make much sense. It only avoids a black screen during sdr/hdr switch.

Probably should be merged as is if it doesn't break other setups.

@UjinT34 I do want to make the always-on HDR experience as good as possible, like it was from my time using KDE. I like the Auto-HDR feature, and I make use of it a lot, but sometimes I get tired of waiting for a modeset when I toggle fullscreen.

My monitor is a Mini-LED, and its local dimming feature is funky in SDR mode. Consuming media in general looks better with HDR on as long as the SDR -> HDR conversion is okay, which I did #12094 to address.

My monitor is a Mini-LED, and its local dimming feature is funky in SDR mode. Consuming media in general looks better with HDR on as long as the SDR -> HDR conversion is okay, which I did #12094 to address.

I'm on the same boat, miniled with long modeset times, that's why I use cm=edid (or alternatively cm=wide) to avoid the modeset.

When autoHDR kicks in, the modeset is instant since wide is already in the correct mode, at least on my case. Cba to calibrate cm=hdr since it looks horrendous on my monitor ootb.

Finally got around to testing cm_fs_passthrough = 1. Both on main and with this branch, the monitor stays in HDR mode and still blows out the colors. Only difference is that with this branch, the colors aren't blown out with cm_fs_passthrough = 2, because DS content falls through and blows out the colors anyway. non_shader_cm = 0 doesn't help without this PR.

So this branch is an improvement (fixes cm_fs_passthrough = 2), but maybe there's a problem with cm_fs_passthrough = 1 on my setup.

Rebased and acknowledged different cm_fs_passthrough settings

It seems this fixes the issue where cm_fs_passthrough = 1 would oversaturate and darken windows made to be fullscreen regardless of direct_scanout's setting.

FWIW I'm not thrilled about the verbosity introduced by the handling of render:cm_sdr_eotf, but come v2 of the color management protocol, the behavior of render:cm_sdr_eotf=2 would be the default, so we could clean things up then.

Ref: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/442
KWin already did this: https://invent.kde.org/plasma/kwin/-/merge_requests/8059

Can't test actual HDR right now but on SDR with a color profile it no longer makes color inaccurate in fullscreen (unless cm_fs_passthrough = 1 is set but not sure if anything can be done about that) so lgtm

Can't test actual HDR right now but on SDR with a color profile it no longer makes color inaccurate in fullscreen (unless cm_fs_passthrough = 1 is set but not sure if anything can be done about that) so lgtm

HDR Content looks normal to me. Also, the colors are fixed in full screen for me with cm_fs_passthrough=1 .

@Arisa-Snowbell, so what you are saying is that for me, SDR to SDR is fixed when that option is NOT set, but for you on HDR (to HDR?) is fixed ONLY when that is set?

@UjinT34 Thoughts on this one? It's been working for my needs, but I want to make sure it isn't regressing anything.

Hard to tell at a glance. The conditions are too complicated now. DS in general doesn't work for me with wine-wayland and I don't use cm = hdr. So those issues come unnoticed by me. Probably we should merge it and look for any bug reports.
#11000 should simplify most of this stuff. It's not ready for testing though and I'm not actively working on it.

@vaxerski

is this ready?

@vaxerski Yessir. I haven't found any issues in my use patterns at least.